Point-of-Service Systems
In OpenHIE, a point-of-service system is anything where health data is created or consumed at the place care happens. They are the edge of the architecture and, from the exchange's perspective, the least controllable part of it: they are procured separately, upgraded on their own schedules, and often predate the exchange by a decade.
The architectural discipline is therefore not to standardise the point-of-service layer, but to standardise what the exchange demands of it.
The categories
| Category | Creates | Typical exchange need |
|---|---|---|
| EMR / EHR | Encounters, diagnoses, medications, observations | Push clinical summaries; look up patient identity; retrieve prior records |
| Community health worker app | Household registrations, home visits, referrals | Offline-first sync; identity resolution; referral tracking |
| Laboratory information system | Orders, specimens, results | Receive orders, return results (LOINC-coded) |
| Pharmacy / dispensing | Prescriptions, dispensing events | Receive prescriptions; report stock consumption |
| Radiology / PACS | Imaging studies, reports | DICOM storage; report as document or observation |
| Logistics (LMIS) | Stock on hand, requisitions, receipts | Product catalogue alignment; facility identity |
| HMIS | Aggregate indicators | Consume aggregates or events; facility identity |
| Insurance / claims | Eligibility checks, claims | Client identity; provider identity; coded services |
| Client-facing apps | Self-reported data, appointment requests | Authenticated patient access; consent |
An OpenHIE architecture does not require all of these. It requires that the ones that exist agree about identity and vocabulary.
What the exchange requires of a point-of-service system
This list belongs in a procurement specification. Systems that cannot meet it should not be bought, whatever else they do well.
- Use the shared client identifier, or be able to store and return one alongside its local identifier. A system that can hold only one identifier per patient cannot participate in a federated ecosystem.
- Use the shared facility identifier from the facility registry — including for sub-units, if the reporting model distinguishes them.
- Identify the health worker using the health worker registry identifier, not a local username.
- Emit data in an agreed standard — normally FHIR against named profiles, or HL7 v2 for laboratory and ADT traffic.
- Code data against agreed terminology — LOINC for observations, SNOMED CT or ICD for problems, per the terminology binding decisions.
- Authenticate to the exchange with a machine identity, not a shared password embedded in a config file.
- Behave when the exchange is unavailable — queue and retry with backoff, never silently drop, never block clinical work.
- Record provenance — which system and which user asserted the data.
- Support a defined error contract — so that a rejected message produces an actionable message to a human, not a log line nobody reads.
The integration adapter pattern
Most point-of-service systems will not implement the exchange's interface natively. Rather than modifying each one, put an adapter between the system and the interoperability layer:
┌──────────────┐ native format ┌───────────┐ FHIR/HTTPS ┌────────────┐
│ Legacy LIS │────────────────────▶│ Adapter │───────────────▶│ IOL │
│ (HL7 v2.3) │◀────────────────────│ (mediator)│◀───────────────│ │
└──────────────┘ └───────────┘ └────────────┘
maps codes,
resolves identity,
handles retries
This is an anti-corruption layer: the exchange's model does not leak into the legacy system, and the legacy system's quirks do not leak into the exchange. It also localises the change when the legacy system is eventually replaced.
The adapter usually runs as a mediator inside OpenHIM or as a channel in an integration engine.
Onboarding a new point-of-service system
A repeatable process, worth writing down once and reusing:
- Register the system — a machine identity, credentials, and a named technical owner who answers the phone.
- Agree the use case — one specific exchange, not "integration" in general.
- Map identifiers — how the system's local IDs relate to shared ones, and what happens when there is no match.
- Map terminology — local codes to the national value sets. Expect this to take longer than the technical work.
- Build and test the adapter — against a sandbox environment with synthetic data, never production.
- Conformance test — profile validation, negative cases, error handling, behaviour under outage.
- Pilot in one facility, with a rollback plan.
- Monitor — message volume, error rate, latency. See observability.
Steps 3 and 4 are the schedule. Teams that plan for steps 5 and 6 and treat 3 and 4 as prerequisites are the ones that overrun.
Open-source point-of-service systems
| System | Category | Notes |
|---|---|---|
| OpenMRS | EMR | Concept-dictionary based; FHIR module available |
| OpenEMR | EMR / practice management | Ambulatory focus, long-established |
| Bahmni | EMR + hospital | Built on OpenMRS, OpenELIS and Odoo |
| GNU Health | Hospital / HMIS | Includes hospital management and lab modules |
| OpenELIS Global | Laboratory | Used in several national deployments |
| CHT (Community Health Toolkit) | CHW app | Offline-first, SMS-capable |
| DHIS2 | HMIS (and Tracker as a point-of-service) | Aggregate reporting plus individual-level tracker |
| OpenLMIS | Logistics | Supply chain and stock management |
| openIMIS | Insurance | Claims and beneficiary management |
Each entry is Tier 2 (established open-source community). Check current activity before committing — see the platform directory for verification dates.
References
- OpenHIE architecture — https://ohie.org/
- OpenMRS — https://openmrs.org/
- OpenELIS Global — https://openelis-global.org/
- Community Health Toolkit — https://communityhealthtoolkit.org/
- OpenLMIS — https://openlmis.org/
- openIMIS — https://openimis.org/